The Intelligent Printer Data Stream (IPDS) architecture provides a structured field data stream that manages printer processes in a bi-directional manner that is independent of the communication means and the transmission protocol. Both IPDS commands and page description data are packaged in the data field of the transmission protocol and sent to the printer; the printer is enabled to respond with appropriate acknowledgements thereby enabling error recovery, resource management and print job auditing. U.S. Pat. No. 4,651,278 incorporated herein by reference, describes the printer interface process known commercially as IPDS. Reference may also be made to the manual "IPDS Reference," S 544-3417, Data Stream and Object Architecture Library, available from the International Business Machines Corporation.
The Intelligent Printer Data Stream (IPDS) is used to provide print jobs to a printer from a print driver that utilizes the IBM Print Services Facility (PSF). Historically, the Print Services Facility has sent large production print jobs that have been provided to it from a mainframe and spooled. As a consequence, the typical system included one print source, one print driver and one printer. With the advance of computer technology, PSF is now used for print jobs originating on mid-sized computers such as an IBM AS400, or workstations such as an IBM RISC6000 and on personal computers. As a result more than one PSF print driver is sometimes now connected to the same printer. Also, there can be print drivers other than PSF present in a system and connected to the same printer. For example, a system might have a PSF print driver, a PostScript print driver and a Printer Control Language (PCL) print driver all connected to the same printer. Additionally, the PSF print driver may be able to send not only an IPDS data stream but may be capable of sending non-IPDS such as a PostScript data stream and a PCL data stream to the same printer. The various data streams have particular logical sockets at the printer to which they are connected.
When a non-IPDS data stream from a non-IPDS print driver is connected to a printer together with an IPDS data stream from a PSF print driver, it was discovered that problems could occur in the interleaving of IPDS print jobs with non-IPDS print jobs, that is, the pages in the stacker were mixed between more than one print job. This occurred because, unlike the historical configuration, the Print Services Facility did not have sole control over the printer. With more than one print driver connected to the printer, given the right combination of time-out values and delay in sending data to the printer (such as when the computer on which PSF is running becomes very busy or when PSF is processing a complex data stream) the printer inactivity timer could time-out and switch to a different socket for the printing of a job present at that socket. The problem was solved by utilizing the bi-directional nature of the IPDS architecture, that is, the IPDS architecture provides for the printer to "speak" to the print driver as well as receive a data stream from the print driver. Thus, an IPDS command, the "Manage IPDS Dialog (MID)" command, was added to the IPDS command structure in order to provide a code signaling the start of an IPDS dialog and a second code signaling the end of an IPDS dialog. The command included an exception code through which the printer could request the print driver to end the IPDS dialog. That action would be taken, for example, when the printer receives a request to print from another session, for example, PostScript. In that manner, PSF is alerted to the fact that the printer has other work to do thereby enabling PSF to break the IPDS data stream at an appropriate point such as at the conclusion of the current print job in order to allow the printer to print from a job request received from a different print driver. In that manner, the IPDS job is not interrupted until it is finished and there is no interleaving of the IPDS job with a non-IPDS job in the print stacker. This feature prevents the interleaving of jobs and also enables the user to print a short job between IPDS print jobs which are often long production runs.
When the printer switches from the IPDS dialog, it saves the IPDS state (IPDS is a state machine) and unless resources allocated to IPDS are needed to service the non-IPDS job, the IPDS state is retained. Should the printer need resources which have been previously allocated to IPDS, those resources are freed in order to do the non-IPDS print job. When returning to IPDS, the first IPDS command received by the printer results in the printer flowing a NACK (Negative Acknowledgement) to PSF, informing PSF that it is necessary to reinitialize the session to establish the resources needed to continue printing IPDS jobs.
In the past when a PSF print driver was requested to send a PostScript data stream, a PCL data stream, or some other non-IPDS data stream to a printer, the print driver would first rasterize the non-IPDS data stream into page images which were then sent with an IPDS data stream. This has advantages since the IPDS data stream implements a bi-directional architecture thereby enabling the printer to send acknowledgements to the print driver and allowing sophisticated error recovery, resource management, and print job auditing. However, if the printer has the capability of rasterizing the non-IPDS data stream, it is considerably more efficient to send the non-IPDS data stream directly to the printer. To do that, however, the printer had to time out before it could switch to processing the non-IPDS job. After timing out it could then service a job present on a different socket presenting a different data stream. Also, in a configuration where more than one PSF print driver is present, different IPDS data streams can be sent to the same printer This case also required a printer time-out before the switch could be made from one IPDS print driver to another.